If I understood this correctly, this could eventually make #587 obsolete. I'm not sure whether one could make this even more generic, as in

"KHR_glsl_shader_versions" : {
    "shaderRef0" : {
         "api" : "gl"
         "version" : "140 es";
         "uri" : "shader140es.vert";
    },
    "shaderRef1" : {
         "api" : "vulkan"
         "version" : "100";
         "uri" : "vulkan.spirv";
    }
}

but this is a wild guess - as pointed out in the linked issue, this is a difficult topic (that I'm not really familiar with), and requires careful thoughts by the respective experts.

That generally sounds like a good idea. Specifying the GLSL version would allow an application to select an appropriate version for the platform.

However, I would make it an array and make the distinction between OpenGL and OpenGL ES. Also note that this extension is specifically for GLSL. I have a separate extension for SPIRV, which will also be supported by OpenGL, OpenGL ES and Vulkan.

"KHR_glsl_shader_versions" : [
    {
         "api" : "opengl",
         "version" : "140",
         "uri" : "opengl_glsl140.vert"
    },
    {
         "api" : "opengles",
         "version" : "130 es",
         "uri" : "opengles_glsl130es.vert"
    },
    {
         "api" : "vulkan",
         "version" : "450",
         "uri" : "vulkan_glsl450.vert"
    }
]

I have updated the extension accordingly. Thanks!

Again, the idea is very vague. Whether it should/could be

"api" : "opengl"
"version" : "130 es"

or

"api" : "opengles"
"version" : "130"

are things that have to be sorted out by the experts, because I can't say which level of detail or structure would be most appropriate here.

My main point was about the fact that the strings "uriGlslOpenGLES" etc. haven't been specified in any form. They could only be matched (verbatim) by the client, and did not contain more detailed version infos. Considering the differences between the shader versions (that you pointed out in the other PRs), an additional version information may be reasonable.

A basic guideline of how the client is supposed to use this information could also be helpful - something like "Pick the shader based on the "api", then the highest version that you support. If you don't find one, then...". But this may be a next step.

OpenGL and OpenGL ES are different APIs with different features and extensions so I do think it is important to make the distinction.

Valid point about adding guidelines for how a glTF loader is supposed to use this data.

We should probably also list the extensions used per shader so a glTF loader can check whether those extensions are support on the platform:

"KHR_glsl_shader_versions" : [
    {
        "api" : "opengl",
        "version" : "140",
        "uri" : "opengl_glsl140.vert"
    },
    {
        "api" : "opengles",
        "version" : "130 es",
        "extensions" : [
            "GL_OVR_multiview2"
        ],
        "uri" : "opengles_glsl130es.vert"
    },
    {
        "api" : "vulkan",
        "version" : "440 core",
        "extensions" : [
            "GL_EXT_shader_io_blocks",
            "GL_ARB_enhanced_layouts"
        ],
        "uri" : "vulkan_glsl440core.vert"
    }
]

Thanks Marco, this has been some really good feedback!

Regarding the extensions: I'm not sure about the best way to differentiate/specify this, but note that this may be strongly related to the glExtensionsUsed that is introduced in glTF 1.1: https://github.com/lexaknyazev/glTF/tree/ecfc8f69bb5c6e5d92aaf995831c7287d8083b50/specification#specifying-gl-extensions

Thanks, I had not see that yet. That would lock a glTF into a specific platform which I think is wrong. Specifying the GL extensions per shader allows an one glTF to support various different platforms, in particular in combination with KHR_spirv_shader_versions, KHR_hlsl_shader_versions and KHR_metalsl_shader_versions.

This point about the possible side effects of the glExtensionsUsed may be important. As glTF 1.1 is not completely finalized, maybe @lexaknyazev and @pjcozzi should have another look at this...

Perhaps archive this if others want to pick it up? CC #1548

I suppose this would need to be reworked given that shaders were moved to KHR_techniques_webgl.